1. Field of the Invention
The present invention generally relates to communication via networks and, more particularity, to managing a tunneling protocol. Tunneling protocols are widely used in modem day communication to allow a protocol to be tunneled over different physical, logical, or virtual mediums.
2. Background Description
One of the largest networks in the world is the Internet. The Internet is a network of worldwide-interconnected computers. One of the organizations that designs new protocols for the Internet is the Internet Engineering Task Force (IETF), and this group has developed/standardized such protocols as IP (Internet Protocol) as well as many others. Of these many protocols that the Internet Engineering Task Force (IETF) has standardized several can be described as tunneling protocols.
Tunneling protocols are used widely for various purposes. These purposes are all related to either information hiding, adding needed functionality, or improving current functionality. Usually, but not always, the tunnel uses unicast addresses, and so the tunnel is usually setup between two nodes. When multi-cast, multi-unicast or broadcast addressing is used, it allows the tunnel to be set up between multiple devices. However, even then, some tunneling mechanism is required to coordinate the group of nodes to participate in the tunnel.
Tunneling is a technology that enables one network to send its data via another network's connections. Tunneling works by encapsulating one protocol within packets carried by the second network. For example, Microsoft's PPTP technology enables organizations to set up tunnels across the Internet and other Internet Protocol (IP) based networks. As with all tunneling protocols, this tunneling is performed, in essence, by encapsulating the native protocol of the user's network with a PPTP envelope as well as an IP envelope. The IP envelope forms the tunnel between the two PPTP servers, and the PPTP envelope is used for controlling the tunnel.
Another protocol that the Internet Engineering Task Force (IETF) has standardized is the Point to Point Protocol (PPP). It is used to allow Internet Protocol (IP) and other protocols (such as IPX, XNS, AppleTalk, etc.) to be sent over non-IP mediums such as the Public Switched Telephone Network (PSTN), ATM, Frame Relay, SONET, etc. Point-to-Point Protocol (PPP) is designed to allow two nodes running like protocols (i.e. IP, IPX, XNS, AppleTalk, etc.) to communicate over a network that has a dissimilar functionality. So in essence Point-to-Point Protocol (PPP) can be thought of as a tunneling protocol.
Much of the modem day Internet is based on the paradigm of end users calling from a home/business computer to an Internet Service Provider (ISP). This paradigm then has the end users calling from their personal computer over the Public Switched Telephone Network (PSTN), Asymmetric Digital Subscriber Line (ADSL), etc to an Internet Service Provider (ISP). So both the physical and protocol layers that are below Point-to-Point Protocol (PPP) are terminated at both the end-users's communication equipment and the Internet Service Provider (ISP)'s Network Access Server (NAS) communications equipment.
For example, Internet calls between an end user at home to an Internet Service Provider (ISP) would normally be established over the Public Switched Telephone Network (PSTN) with the telephone call being between the end user's MODEM and the ISP's Network Access Server (NAS). The Point-to-Point Protocol (PPP) session would then be established from the end user's home computer to the ISP's Network Access Server (NAS). The NAS would then typically terminate both the Public Switched Telephone Network (PSTN) and the Point-to-Point Protocol (PPP) session. So on one side of the Network Access Server (NAS) is the Public Switched Telephone Network (PSTN) and Point-to-Point Protocol (PPP) input/output (I/O), while on the other side the NAS's I/O is Internet Protocol (IP). Those skilled in the art will recognize that a NAS is a gateway between the Public Switched Telephone Network (PSTN) and the Internet. Further, those skilled in the art will realize that a Network Access Server (NAS) may be any gateway device, such as Digital Subscriber Line Access Multiplexer (DSLAM), that interconnects two dissimilar networks such as IP, IPX, XNS, PSTN, ISDN, SS7, AIN, Cable Modems, etc.
The Network Access Server (NAS) then is usually responsible for terminating the Public Switched Telephone Network (PSTN) call as well as the Point-to-Point Protocol (PPP) session, extracting the Internet Protocol (IP) packets from the Point-to-Point Protocol (PPP) Protocol Data Units (PDUs), and usually assigning a temporary Internet Protocol (IP) address to the end user's Internet Protocol (IP) session. Further, the Network Access Server (NAS) performs Authentication, Authorization and Accounting (AAA) functions for the Internet Service Provider (ISP). These AAA functions are used for ensuring a secure Internet access offering is provided where the Internet Service Provider (ISP) can accurately bill the user for services rendered, and to ensure that unauthorized users are not allowed to use the service.
The traditional paradigm of having a Network Access Server (NAS) controlled and dedicated to the use of a single Internet Service Provider (ISP) has been changing in recent years. In its place is a new class of virtual dial-up applications, which allow multiple protocols, unregistered Internet Protocol (IP) addresses, and foreign Internet Protocol (IP) addresses to be used by the end user's computer. Because of the routing and packet forwarding conflicts caused by these new virtual dial-up applications, a tunneling protocol was needed to allow the physical and protocol layers below Point-to-Point Protocol (PPP) to be terminated by the Network Access Server (NAS), and then the Point-to-Point Protocol (PPP) Protocol Data Units (PDUs) themselves to be tunneled to another remote device. So in essence, the Network Access Server (NAS) function has been separated into two devices. One device handles the termination of the physical and logical layers below Point-to-Point Protocol (PPP), and then a second device terminates the Point-to-Point Protocol (PPP) stream itself.
The Internet Engineering Task Force (IETF) developed the L2TP (Layer Two Tunneling Protocol) to allow the Point-to-Point Protocol (PPP) to be tunneled over the Internet and so allowing the separation of Network Access Server (NAS) functions. L2TP comprises two main devices; namely, the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). The LAC is co-located with the NAS and forwards a PPP stream to the LNS where the PPP stream is terminated.
The L2TP Access Concentrator (LAC) is a device attached to a switched network fabric (such as, for example, PSTN or ISDN) or co-located with a PPP end system capable of handling the L2TP protocol, while the L2TP Network Server (LNS) operates on any platform capable of PPP termination. In other words, the LAC provides the user side of the L2TP protocol, while LNS handles the server side. The LAC is the initiator of incoming L2TP calls (calls initiated from a General Switched Telephone Network (GSTN) edge device), and the LNS is the initiator of outgoing L2TP calls (calls initiated for a PSTN edge device). The LAC and the LNS then allow Point-to-Point Protocol (PPP) calls to be tunneled through the NAS and the Internet. This then allows the PPP session to be established between an end user and the LNS. The Network Access Server (NAS) is a device providing temporary, on-demand network access to users. The PPP communication session is typically point-to-point, with the NAS interconnected to the end-user via the PSTN.
The LAC must connect to the full range of networks that it wishes to accept callers from; for example, PSTN, ISDN, ADSL, etc. However, the LNS has no such requirement. Instead, the LNS's main connectivity requirement (in order to allow intercommunications with the LAC) is to have network layer connectivity to the LACs that it wishes to communicate with.
A further change to the traditional Network Access Server (NAS) paradigm is that Incumbent Local Exchange Carriers (ILECs) and Competitive Local Exchange Carriers (CLECs) are beginning to offer Network Access Server (NAS) services, where Internet Service Providers (ISPs) and businesses can purchase either virtual or physical Network Access Server (NAS) resources. Then the Incumbent Local Exchange Carrier (ILEC)/Competitive Local Exchange Carrier (CLEC) Network Access Servers (NASs) tunnel the multiple Point-to-Point Protocol (PPP) calls to their intended destination with the use of L2TP. This allows the physical and logical layers below Point-to-Point Protocol (PPP) to be terminated by the ILEC/CLEC Network Access Server (NAS) service and the Service Providers (SPs) to terminate the Point-to-Point Protocol (PPP) sessions. Because of both business and regulatory reasons, these new ILEC/CLEC Network Access Server (NAS) hosting services will be significantly expanding. Those skilled in the art will recognize that a Service Provider (SP) may be an Internet Service Provider (ISP), business needing dial-in access, or any other entity requiring dial in services but lacking the requirement to host a Network Access Server (NAS) themselves. Also, those skilled in the art will recognize that not only ILECs or CLECs may provide this Network Access Server (NAS) hosting service, but also Inter-eXchange Carriers (IXCs), Internet Service Providers (ISPs), or any type of carrier may offer the service.
The Network Access Server (NAS) hosting service will probably need to be located at each Central Office (CO), and so L2TP tunnels must be set up between every central offices's NAS L2TP Access Server (LAC) and their respective L2TP Network Server (LNS) Point-to-Point Protocol (PPP) termination point. Those skilled in the art will readily see that this creates a large manageability problem. For example, if 100 service subscribers subscribe to this hosting service and each has two LAC/LNSs, for redundancy purposes, then there would be 200 possible LNSs that each NAS/LAC must be configured for which to also establish subsequent L2TP tunnels. Further, if 1000 central offices have a hosting service, then 20,000 L2TP tunnels must be configured and maintained. This obviously, is a major problem with providing the service.
The problem then with the use of tunneling protocols is that they are designed for either point to point or some other defined group use. This means that no merging of the thousands of tunnels is possible and that a large service such as a Incumbent Local Exchange Carrier (ILEC) or Competitive Local Exchange Carrier (CLEC) Network Access Server (NAS) hosting service will not scale to a large amount of NASs/LACs and L2TP Network Server (LNS) termination points. Further, managing the large number of tunnels individually would add significant operational cost and complexity.
In the traditional case, the L2TP LAC would be located at the ILEC/CLEC NAS hosting service and then the L2TP LNS would be located at either the ISP or the business subscribing to the NAS hosting service. Those skilled in the art will realize that while it is more likely to have the LAC with the NAS, it is possible to have the LNS located at the NAS as well. Further, those skilled in the art will realize that while the Internet will commonly be used to transport the L2TP sessions, it is also likely that other networks such as Intranets, Public Data Networks (PDNs), and even non-IP networks could be used in its place. Those skilled in the art will realize that the L2TP tunneling protocol could be substituted with other tunneling protocols such as IP/IP (RFC 1853), GRE (RFC 1702), MPLS, IPSEC, proprietary tunneling implementations, etc. Those skilled in the art will also realize that not just IETF standards could-be used for the tunneling protocols. Any tunneling protocol from the plethora of other standard bodies and organizations such as the ITU, ADSL Forum, ATM Forum, etc., could be used instead.
Those skilled in the art will realize that the description of IP network based tunneling is done for illustrative purposes. Other non-IP tunneling mechanisms would have the same problems. For example, if X.25 was tunneled over a Frame Relay PDN, then the same scaling problem could be experienced. So this same problem would exist in non-IP based networks such as IPX, Frame Relay, ATM, X.25, etc.